The following relates to device requests made to USB devices and to methods of implementing device requests that are defined by a host system rather than by the USB standard or by the device itself.
The Universal Serial Bus (USB) is a cable bus that supports data exchange between a host computer and a wide range of simultaneously accessible peripheral devices. The attached peripheral devices share USB bandwidth through a host-scheduled, token-based protocol. The bus allows peripherals to be attached, configured, used, and detached while the host and other peripherals are in operation.
The USB is defined by a specification that is approved by a committee of industry representatives. The specification covers all aspects of USB operation, including electrical, mechanical, and communications characteristics. To be called a USB device, a peripheral must conform to this very exacting specification.
One significant feature of USB is that it allows peripheral devices to store information about themselves, and to provide such information upon request to host computers. This avoids the need for the computer, operating system, or application programs to maintain this information for many different devices. Instead, the device stores and provides its own information.
The USB device information is typically stored in so-called xe2x80x9cdescriptorsxe2x80x9dxe2x80x94data structures formatted as specified by the USB specification. These descriptors contain information that is primarily related to device controls joysticks, buttons, wheels, sliders, etc.). They describe the type of each control, the format of data generated by the control, the range of values generated by the control, and many other characteristics.
In defining the USB communications protocol, the USB committee attempted to foresee future needs, and to provide ways to accommodate such needs within the existing protocol. In addition, the USB specification is updated from time to time, thereby providing a mechanism for adding further functionality while still retaining backward compatibility.
It was recognized from an early date that certain peripherals might need to define their own descriptors or request codes, relating to new features or technology not encompassed by the USB-defined descriptors. This capability was provided by reserving certain request codes for definition and use by individual peripheral manufacturers.
Request codes are used in a USB system to define xe2x80x9cdevice requestsxe2x80x9d from a host to a peripheral device. A device request is a data structure that is conveyed in a xe2x80x9ccontrol transferxe2x80x9d from the host to the peripheral device. A control transfer contains the following fields:
bmRequestTypexe2x80x94a mask field indicating (a) the direction of data transfer in a subsequent phase of the control transfer; (b) a request type (standard, class, vendor, or reserved); and (c) a recipient (device, interface, endpoint, or other). The primary types of requests specified in the xe2x80x9crequest typexe2x80x9d field are the xe2x80x9cstandardxe2x80x9d and xe2x80x9cvendorxe2x80x9d types, which will be discussed below.
bRequestxe2x80x94a request code indicating one of a plurality of different commands to which the device is responsive.
wValuexe2x80x94a field that varies according to the request specified by bRequest.
wIndexxe2x80x94a field that varies according to request; typically used to pass an index or offset as part of the specified request.
wLengthxe2x80x94number of bytes to transfer if there is a subsequent data stage.
All USB devices are supposed to support and respond to xe2x80x9cstandardxe2x80x9d requests-referred to herein as xe2x80x9cUSB-specificxe2x80x9d requests. In a USB-specific request, the request type portion of the bmRequestType field contains a predefined value indicative of the xe2x80x9cstandardxe2x80x9d request type.
Each different USB-specific request has a pre-assigned USB-specific request code, defined in the USB specification. This is the value used in the bRequest field of the device request, to differentiate between different USB-specific requests. For each USB-specific request code, the USB specification sets forth the meanings of wValue and wIndex, as well as the format of any returned data.
USB devices can optionally support xe2x80x9cvendorxe2x80x9d requestsxe2x80x94referred to herein as xe2x80x9cdevice-specificxe2x80x9d requests. In a device-specific request, the request type portion of the bmRequestType field contains a predefined value to indicate a xe2x80x9cvendorxe2x80x9d request type.
In the case of device-specific requests, the USB specification does not assign request codes, define the meanings of wValue and wIndex, or define the format of returned data. Rather, each device has nearly complete control over the meaning, functionality, and data format of device-specific requests. Specifically, the device can define its own requests and assign device-specified request codes to them. This allows devices to implement their own device requests for use by host computers, and provides tremendous flexibility for manufacturers of peripherals.
The inventors have discovered a need for a similar feature that would benefit various hosts, application programs, and host operating systems. Specifically, designers of application programs and operating systems would value the opportunity to define their own device requests (and the associated responses), and to have such requests supported in a uniform way by compatible peripherals.
As an example of this need, a co-pending US Patent Application (xe2x80x9cSystem and Method for Mapping Input Device Controls to Software Actions,xe2x80x9d Ser. No. 09/483,113, filed Jan. 10, 2000), describes a technique in which different controls of a device are arranged in different combinations for use with application programs of different xe2x80x9cgenres.xe2x80x9d For each genre, the controls of the device are enumerated along with standard xe2x80x9cactionsxe2x80x9d that are to be initiated in response to the respective controls.
Although such information can be maintained at the host for various different controllers, it would be desirable for each controller to store its own genre information, and to make it available through a predefined USB device request. However, such a device request is not defined by the USB specification.
Ideally, a device request such as this would be defined by the host or by the manufacturer of an operating system that executes on the host, and supported uniformly by peripheral devices. Because of this, the device request might be referred to as a xe2x80x9chost-specificxe2x80x9d device requestxe2x80x94in contrast to xe2x80x9cUSB-specifiedxe2x80x9d requests and xe2x80x9cdevice specificxe2x80x9d requests.
However, the different request types supported in the bmRequestType field of a USB device request do not include a xe2x80x9chostxe2x80x9d type of request.
One possible solution to this problem would be to simply usurp a vendor-specific request code, and attempt to persuade all device manufacturers to use this request code to initiate an agreed-upon host-specific device request. However, this would not provide backward compatibility in the case that the chosen request code was used in previously manufactured devices for different, vendor-specific requests.
Another possibility might be to work with the USB committee to define a new type of requestxe2x80x94possibly including a range of request codes for use by host computers. However, this would be a very long term project, and would not produce results quickly enough to be useful in current host program versions.
Accordingly, the inventors have devised a technique that allows a host system to define and issue host-specific device requests while remaining within the current USB specification and maintaining backward compatibility with previous generations of USB peripheral devices.
Described below is a technique for implementing a host-specific device request in a USB system. The system includes a USB device that responds to device requests from a host. The device requests include USB-specific device requests with corresponding USB-specified request codes and device-specific device requests with corresponding device-specific request codes. The USB-specific requests include a GET_DESCRIPTOR device request that is initiated with a corresponding GET_DESCRIPTOR request code.
The described technique involves two phases. First, the host uses the GET_DESCRIPTOR device request to obtain the request code that corresponds to the host-specific device request. Second, the host uses the obtained request code to initiate the host-specific device request. The first phase is performed once, while the second phase can be performed many times. During the first stage, signature checking is performed to confirm that the device supports this technique. This ensures backward compatibility with earlier devices.